@seanf Thanks for your updates. are we really need these configurations? I think we add too many rules for one file. (index.ts). since this is not a big project and we have support tslint already.

@BANG88 I think tslint is better at checking for coding anti-patterns, but maybe not the best option for checking code formatting. (In fact I just found a little library tslint-config-prettier which turns off tslint's styling rules in favour of prettier's.)

https://prettier.io/docs/en/why-prettier.html

prettier seems to be good for keeping the style consistent with a minimum of fuss, which is helpful for collaboration. I already found that PR #10 had inconsistent indenting, and, as it turns out, so did my changes in extractMessagesForFormatMessage. I was also having a little trouble deciding the best way to format some of the complex conditionals (and there are quite a few in this little project).

If you run yarn build it will auto-format index.ts, so we won't have to follow the formatting rules manually. tslint has a --fix option which may be able to do some of this, but I think it makes code changes too, so prettier seems like the more conservative option here.

Once it's set up it shouldn't require much from us, since it's mostly automatic.

Yep. I use prettier and tslint in our projects. If we want a same coding style then I choose prettier if we want some variable naming or something else I prefer tslint. But I do agree with you. using prettier for code format is a good idea.

@seanf

@BANG88 Great.

In that case, would you prefer to use prettier's default options for consistency (eg with your other projects)? I originally changed a couple of rules to fit in with tslint, until I realised that it was better to turn off tslint's formatting rules with tslint-config-prettier.

ie should I delete these exceptions from .prettierrc (and reformat):

# Bring 'prettier' in line with tslint options:
trailingComma: all
arrowParens: always

https://prettier.io/docs/en/options.html#trailing-commas
https://prettier.io/docs/en/options.html#arrow-function-parentheses

No. that's ok.